NFV (Network Functions Virtualization) that realizes the functions of network apparatus by means of software using a virtual machine (VM) implemented on a virtualization layer such as a hypervisor (HV) on a server is known (for instance refer to Non-Patent Literature 1).
FIG. 7 is a drawing showing an outline of a network configuration in a virtualized environment. In FIG. 7, a VNF (Virtualized Network Function) 22 corresponds to an application running on a virtual machine (VM) on a server, and realizes a network function by means of software. A management function called an EM (Element Manager) 23, also known as EMS (Element Manage System), is provided for each VNF 22.
An NFVI (Network Functions Virtualization Infrastructure) 21 is an infrastructure on which hardware resources of a physical machine (PM) such as computing, storage, and network functions can flexibly treated as virtual hardware resources such as virtual computing, virtual storage, and a virtual network virtualized by a virtualization layer such as a hypervisor.
An NFV-Orchestrator (NFVO) 11 of an NFV MANO (NFV Management & Orchestration) 10 orchestrates the resources of the NFVI and manages the lifecycle of a network service (NS) instance (instantiation, scaling, termination, update, etc., of an NS instance).
A VNF Manager (VNFM) 12 manages the lifecycle of a VNF instance (for instance, instantiation, update, query, scaling, termination, etc.) and notifies events.
A Virtualized Infrastructure Manager (VIM) 13 controls and manages the computing, storage, and network resources of the NFVI 21 and failure monitoring and resource monitoring for the NFVI 21.
As for OSS/BSS 30, the OSS (Operations Support System) is a generic term for systems (equipment, software, mechanism, etc.) required for, for instance, telecommunications carriers to construct and operate services. The BSS (Business Support System) is a generic term for information systems (equipment, software, mechanism, etc.) that, for instance, telecommunications carriers use for billing and charging usage fees and customer services.
In the network system shown in FIG. 7, the VIM 13 manages an image file necessary for instantiating the VNF 22. The VIM 13 instantiates the VNF 22 by providing the image file to the NFVI 21. In a network system in a virtualized environment, a target software version can be specified by the VNF software image management interface described in “7.2.2 VNF software image management” of Non-Patent Literature 1. More specifically, in “Figure B.2: VNF Package on-boarding message flow” in “B.2.1 On-board VNF Package flow” of Non-Patent Literature 1, the NFVO 11 provides an image file to the VIM 13 using the software image management interface in response to a request from a sender. Note that the VNF software image management interface is referred to as the “Software Image Management Interface” in the chapter 7.2 of Non-Patent Literature 2.
The description above using FIG. 7 explains a virtualization technology in which a virtual machine (VM) is created by a virtual function (hypervisor) implemented on a physical machine (PM). In recent years, in addition to the virtualization technology using the virtual machine (VM), the virtualization technology using a container has gained attention. The container type virtualization technology has various advantages; an operating system (OS) is not required for each container, and a container can become available quickly on a physical machine (PM).
A container type virtualization technology uses software called container engine (the container engine is installed on a physical machine or virtual machine). In recent years, Docker comprising a stack management function related to an image of an application (virtual server) has been released as open source and is often used as a container engine.
Docker comprises a function of allowing an application to manage an implemented execution environment as an execution image, and the specifications of a Docker repository (also known as the Docker registry) that manages this image is published in Non-Patent Literature 3.
Further, a framework called “Magnum” for making a Docker container available in OpenStack is under consideration. Magnum is an OpenStack API (Application Programming Interface) and is able to construct and operate a Docker virtualized environment with commands.
For instance, with reference to FIG. 8, Docker provides a command (docker.build) for building a Docker image and registering it in a repository and a command (magnum.pod-create) for starting a Docker image. Further, Magnum interfaces, etc., are published in Non-Patent Literature 4.    [Non-Patent Literature 1]    ETSI GS NFV-MAN 001 V1.1.1 (2014-12) Network Functions Virtualisation (NFV); Management and Orchestration (retrieved on Jun. 14, 2016), <http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_NFV-MAN001v010101p.pdf>    [Non-Patent Literature 2]    ETSI GS NFV-IFA 005 V2.1.1 (2016-04) Network Functions Virtualisation (NFV); Management and Orchestration Or-Vi reference point—Interface and Information Model Specification (retrieved on Jun. 14, 2016), <http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/005/02.01.01_60/gs_nfv-ifa005v020101p.pdf>    [Non-Patent Literature 3]    The Docker commands (retrieved on Jun. 14, 2016), <https://docs.docker.com/engine/reference/commandline/>    [Non-Patent Literature 4]    Developer Quick-Start (retrieved on Jun. 14, 2016), <http://docs.openstack.org/developer/magnum/dev/dev-quickstart.html>